\subsection{Konsequenzen der Erweiterbarkeit}
Aus der Ausrichtung auf leichte Erweiterbarket entstehen an verschiedenen Stellen der Implementierung von \RENGA unterschiedliche Konsequenzen.

\subsubsection{Unspezifische Datentypen}
An vielen Stellen im Kern von \RENGA kann keine Einschr\"ankung des Typs gemacht werden. Ein besonders auff\"alliges Beispiel f\"ur diese Konsequenz ist, dass im Kern von \RENGA viele Methoden R\"uckgabewerte vom Typ Object haben. An diesen Stellen l\"asst sich der R\"uckgabewert nicht weiter einschr\"anken, da beliebige R\"uckgabewerte f\"ur Primitive zugelassen werden sollen. Die einzige gemeinsame Superklasse alle m\"oglichen R\"uckgabewerte ist allerdings Object.

\subsubsection{Manuelle Typpr\"ufung}
Da wie angegeben keine weiteren Einschr\"ankungen an die Typen gemacht werden k\"onnen und \RENGA zus\"atzlich zumindest dynamisch typisiert erscheinen soll, muss an vielen Stellen die Korrektheit der Typen festgestellt werden. Dies f\"uhrt zu einer grossen Anzahl von $instanceof$-Vegleichen oder in komplexeren F\"allen zum Einsatz der Reflection-API von Java. 

\subsubsection{Reflection-API}
Java bietet zwar mit der Reflection-API an vielen Stellen die M\"oglichkeit, gro"se Mengen an Informationen \"uber die einzelnen in Verwendung befindlichen Objekte zu sammeln, hierbei sind allerdings zwei Dinge zu beachten:
\begin{enumerate}
\item{Die Reflection-API bietet nur extrem langsam Zugriff auf Informationen \"uber Objekte, ihr Einsatz sollte also, wenn m\"oglich, unterlassen werden.}
\item{Die Reflektion-API befindet sich am Rand der Java-Spezifikation, bei ihrer Verwendung ist an vielen Stellen Vorsicht geboten, da selbst korrekter Java-Code an vielen Stellen zu Abst\"urzen f\"uhrt. In SUNs Fehlerdatenbank \cite{Bugs} gibt es zahllose Beispiele f\"ur solche Fehler.}
\end{enumerate}